Codecov Report

Patch and project coverage have no change.

Comparison is base (bf9932a) 81.75% compared to head (749155d) 81.75%.

❗ Current head 749155d differs from pull request most recent head 6ee5ab6. Consider uploading reports for the commit 6ee5ab6 to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@           Coverage Diff           @@
##             main     #455   +/-   ##
=======================================
  Coverage   81.75%   81.75%           
=======================================
  Files          37       37           
  Lines        2006     2006           
=======================================
  Hits         1640     1640           
  Misses        366      366           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thank you, @msupernaw for your suggestions. There was a display issue with your previous comment, but I've updated it.

In the revised code, "_m" as a prefix for members of the Parameter class has been used. Additionally, the relevant code sections within the selectivity, recruitment, maturity, and TMB interfaces have been updated.

Do we need to consider adding "interface_" as a prefix to those members (see issue #411)? If it becomes necessary during the work on issue #411 , we can implement this change at that time.

Instructions for code reviewer

Hello reviewer, thanks for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete!
• For PRs that don't make changes to code (e.g., changes to README.md or Github actions workflows), feel free to skip over items on the checklist that are not relevant. Remember it is still important to do a thorough review.
• Then, comment on the pull request with your review indicating where you have questions or changes need to be made before merging.
• Remember to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
• PR reviews are a great way to learn, so feel free to share your tips and tricks. However, for optional changes (i.e., not required for merging), please include nit: (for nitpicking) before making the suggestion. For example, nit: I prefer using a data.frame() instead of a matrix because...
• Engage with the developer when they respond to comments and check off additional boxes as they become complete so the PR can be merged in when all the tasks are fulfilled. Make it clear when this has been reached by commenting on the PR with something like This PR is now ready to be merged, no changes needed.

Checklist

• The PR is requested to be merged into the appropriate branch (typically main)
• The code is well-designed.
• The functionality is good for the users of the code.
• Any User Interface changes are sensible and look good.
• Parallel computing remains functional.
• The code isn’t more complex than it needs to be.
• The developer isn’t implementing things they might need in the future but don’t know they need now.
• Code has appropriate unit tests.
• Tests are well-designed.
• The developer used clear names for everything.
• Comments are clear and useful, and mostly explain why instead of what.
• Code is appropriately documented (doxygen and roxygen).
• The code conforms to our style guides.